Thanks for your pull request and interest in making D better, @nordlow! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + phobos#10880"

I don't understand what this pull request is trying to solve.

The point of the inline pragma is to override the optimizer's decisions. It should be used only when the optimizer has made an incorrect decision.

The optimizer is also highly specific to the backend.

I can see how the pragma can be useful in specific scenarios where profiling and disassembling revealed that the specific optimizer has made a suboptimal decision with a specific program. I don't see how this applies to the standard library, which can be compiled by any D compiler.

So, isn't the correct number of pragma(inline) directives in Phobos equal to 0?

Anyway I think it should be measured when adding inline attributes.

So, isn't the correct number of pragma(inline) directives in Phobos equal to 0?

Q: I believe it's useful for cross-module inlining in LDC (although LDC has a cross-module-inlining flag, but it is hidden), and that would affect all programs using the standard library, wouldn't it?

Maybe, but is that the right solution? We would then be using a vendor-agnostic compiler directive to improve one specific vendor's compiler.

cross-module-inlining

Is this enabled by default when doing -O3? If not, why?

Changes to std/internal/unicode_tables.d appear to still exist.

Changes to std/internal/unicode_tables.d appear to still exist.

Fixed.

My main motive for adding these is to reduce run-time of debug builds. The minimum function call overhead for the X86_64 ABI is unnecessary large and D adheres to it. Just count the number of instructions in the assembly output for a minimal function call doing a trivial comparison that can be encoded into a single instruction.